在 90 年代对极限编程有了积极的经验后，我对 Scrum、Crystal 和 DSDM 等类似方法产生了好奇。在深入研究之后，我提炼出这些新方法的共同特征：倾向于适应性计划而不是预测性计划，并将人视为比所用过程更重要的成功因素。随着时间的推移，这些方法汇集在敏捷软件开发的旗帜下（我修改了这篇文章），但我仍然发现本文的观点是理解敏捷本质的好方法。

敏捷方法已成为主流，但这种流行并非没有问题。组织领导者抱怨说，他们没有获得预期的收益。本文介绍了一种流畅度模型，可以帮助您充分利用敏捷理念。流畅度通过四个不同的区域发展，每个区域都有其自身的优势、所需的能力和关键指标。

随着 XP 和其他敏捷方法的普及，关于如何将 XP 扩展到 10-12 人以上的团队的问题开始浮出水面。2003 年 2 月中旬，在加拿大艾伯塔省班夫举行了一次专门讨论该主题的研讨会。在本文中，我们报告了 Ken Schwaber 和 Martin Fowler 以及其他领先从业者的主题演讲。

我小时候讨厌胡萝卜，讨厌它的气味和口感。但在我离家开始自己做饭后，我开始喜欢上它们了。胡萝卜本身没有改变，我的味蕾也没有发生根本性的改变，区别在于烹饪方式。我的母亲和那一代的许多英国人一样，不擅长烹饪，尤其是蔬菜。她的方法是将胡萝卜煮 20 分钟或更长时间。后来我才知道，如果烹饪得当，胡萝卜会带来完全不同的体验。

这不是一个关于烹饪的网站，而是一个关于软件开发的网站。但我发现，一种技术或工具往往就像可怜的胡萝卜一样，因为使用不当而被指责为糟糕，而真正的问题在于技术的使用方式不正确。

当人们使用“软件架构师”一词时，他们是在借用建筑施工中的比喻来帮助人们理解架构师的角色。讽刺的是，这样做反而误解了建筑师的实际角色。

我遇到过各种各样的代码所有制方案。我将它们分为三大类

Daniel Terhorst-North 最近关于软件匠艺的博客文章引发了许多博客讨论（如果您感兴趣，我将在下面总结）。内容很多，但他的一个主题特别引起了我的共鸣，因此有了这篇文章。

精心设计软件是否值得？

两种软件开发态度之一。指导态度认为，由于大多数开发人员的能力都不强（据说几乎 50% 的开发人员的能力都低于平均水平），因此我们需要指导他们做事的方式。这种指导是为了防止他们对正在开发的系统造成损害。通常，这种态度体现在设计和工具中，这些设计和工具会阻止开发人员做某些事情，限制他们可以做的事情，让他们远离复杂领域。

两种软件开发态度之一。赋能态度认为，开发人员是负责任的专业人员，因此应该给予他们做任何需要做的事情的自由。遵循这种态度的设计应该使事情易于使用，但应该假设开发人员知道自己在做什么，因此不要试图阻止某些事情被错误地使用。因此，这些工具可能会被滥用，但要抱着这样的态度，即用户应该更清楚自己在做什么，如果他们不清楚，他们就应该承担一切后果。

敏捷方法中一种常见的、也许是占主导地位的做法是为正在构建的软件开发一个功能列表（通常称为故事）。这些功能通过索引卡、工作队列、燃尽图、积压工作或您选择的任何工具进行跟踪。

我最喜欢的妙语之一是：如果它让你痛苦，就更频繁地去做它。它有一个令人愉快的特性，那就是表面上看起来荒谬，但当你深入挖掘时，它会产生一些有价值的意义

成熟度模型是一种工具，可以帮助人们评估个人或团队当前的效率，并帮助确定他们接下来需要获得哪些能力才能提高绩效。在很多圈子里，成熟度模型的名声都不太好，但尽管它们很容易被滥用，但在正确的人手中，它们还是很有帮助的。

经常阅读我的作品的读者可能知道，我非常怀疑使用其他职业的比喻来解释软件开发。特别是，我认为工程比喻对我们的职业造成了损害，因为它鼓励了将设计与构建分离的观念。

当我在我们伦敦的办公室闲逛时，这个问题在精益制造的背景下出现了，精益制造是一个在敏捷圈子里经常使用的比喻，特别是Poppendiecks。如果我不喜欢土木工程中的隐喻推理，那么我更喜欢精益制造中的隐喻推理吗？

对许多人来说，关于敏捷方法最难理解的事情之一就是敏捷的以人为本。那些对敏捷流程感兴趣的人都同意，流程对项目成功的影響是第二位的。敏捷宣言的第一个价值观是，个人和互动比流程和工具更有价值。

当人们想到代码审查时，他们通常会想到开发团队工作流程中的一个明确步骤。如今，在拉取请求上执行的集成前审查是最常见的代码审查机制，以至于许多人愚蠢地认为不使用拉取请求就消除了所有进行代码审查的机会。这种狭隘的代码审查观点不仅忽略了许多明确的审查机制，更重要的是，它忽略了可能是最强大的代码审查技术，即由整个团队进行的持续改进。

你坐在会议室里，思考着你的团队在过去几年里一直在编写的代码。你已经决定，你现在能做的最好的事情就是扔掉所有代码，在一个全新的架构上重建。你对那些注定要被淘汰的代码、你花在上面的时间、你很久以前做出的决定有什么感觉？

这是第 n 次了，我相信也不是最后一次，我开始讨论定义实践，将其中一些实践标记为“最佳”，可能还有 C 字（认证）。这是一个熟悉的话题，尽管我们才刚刚开始讨论，但我可以预测它的大致走向。它是由一种完全合理的愿望驱动的，即确定谁是更好的软件开发人员，以及现有开发人员如何提高他们的能力。

SEMAT（软件工程方法与理论）是由 Ivar Jacobson、Bertrand Meyer 和 Richard Soley 发起的一项工作。其既定目标是“在坚实的理论、经过验证的原则和最佳实践的基础上重塑软件工程”。和软件界许多声名狼藉的人一样，我也被邀请参加。到目前为止，我一直拒绝参加，我觉得有必要解释一下原因。

守破离是一种思考如何学习一项技术的思维方式。这个名字来自日本武术（特别是合气道），Alistair Cockburn 将其引入作为一种思考学习软件开发技术和方法的方式。

在我的整个职业生涯中，人们总是将软件开发与“传统”工程进行比较，通常是为了斥责软件开发人员没有做好工作。作为一个获得电子工程学位的人来说，这在我职业生涯的早期引起了我的共鸣。但这种想法是错误的，因为大多数人对工程在实践中的运作方式有错误的印象。

软件开发中的许多争论都取决于发言者是持指导态度还是赋能态度。这些不同的态度会影响对语言、设计、工具、流程等的选择。

人们时常质疑某个特定专业是否可以使用渐进的方式：“你不能在敏捷项目中进行（安全 | 用户界面设计 | 数据库 | 国际化 | * ），因为这方面必须预先完成。”

本月将审查 IEEE 的软件工程知识体系指南。这是一项旨在定义我们行业知识体系的工作，以便为获得许可的行业奠定基础。

时间盒迭代是一种划分和安排项目工作的方式，尤其与敏捷软件项目相关。团队将软件的可见功能分解成用户故事，并将时间分解成固定的周期（例如一周），称为迭代。然后，他们通过将故事分配到迭代中来安排故事。故事会进行粗略估计，以便团队能够确定一个迭代中可以容纳多少个故事。

纵观我的职业生涯，我一直看到的一个主题是软件开发的性质和重要性。几年前，一位潜在客户告诉我们的一位销售人员，“软件就像污水管道，我希望它能可靠地工作，我不想知道细节”。这就是尼古拉斯·卡尔在IT 无关紧要中谈到的那种方法。相比之下，我们为许多企业做过工作，在这些企业中，IT 已成为其业务的明显战略推动力，使它们能够进入新市场或显著提高市场份额。那么，IT 究竟是像污水管道一样的公用事业，还是一项战略资产？

在软件领域，“瀑布”通常用于描述一种软件流程风格，它与迭代或敏捷风格的理念形成对比。与软件中许多众所周知的术语一样，它的含义定义不清，起源也不明——但我发现它的基本主题是根据活动将一项大型工作分解成多个阶段。

CHAOS 报告称只有 34% 的项目取得成功。

Standish Group 的CHAOS 报告多年来一直在谈论 IT 项目浪费了数十亿美元。34% 的成功率实际上比 2001 年的 28% 有所提高。但我们所说的“失败”到底是什么意思？

YAGNI 原本是一个首字母缩略词，代表“你现在不需要它”。这是极限编程中的一句口号，在敏捷软件团队中也经常使用。它指的是，我们认为软件将来需要的一些功能现在不应该构建，因为“你现在不需要它”。